Data in a business application is logically organized in one or more object types which represent the different entities supported by the application. Each object type includes one or more attributes which characterize or describe the object type. The object types that are defined during the application development are usually referred to as default object types. The attributes included in a default object type are usually referred to as default attributes of the object type.
Each attribute typically has attribute-identifying information and a data type associated with it. Data stored in each object type is usually organized in a number of object instances. An object instance is a set of data that is uniquely distinguishable from other similar sets of data within the object type, and the data within each object instance is organized in data items corresponding to each attribute of the object type. The data item stored in each attribute is of the data type associated with the attribute.
Application data is physically stored in a repository which is typically implemented as a database management system (DBMS). A DBMS is sometimes also referred to as a database. Data in a DBMS is stored in one or more data containers, each container contains records, and the data within each record is organized in one or more fields. In relational database systems, the data containers are referred to as tables, the records are referred to as rows, and the fields are referred to as columns. In object-oriented databases, the data containers are referred to as classes, the records are referred to as objects, and the fields are referred to as attributes. Other database architectures may use other terminology.
Systems that may implement the present invention are not limited to any particular type of database architecture. However, for the purposes of explanation, the examples and the terminology used herein shall be that typically associated with relational databases. Thus, the terms “table”, “row” and “column” shall be used herein to refer respectively to the data container, record, and field.
In the application data repository, object types are usually mapped to tables, object instances are usually mapped to rows, and object type attributes are usually mapped to columns. However, one-to-one mappings between object types and tables, between object instances and rows, and between object type attributes and columns are not required. In complex applications a single object type may be mapped to several tables, a single object instance may be mapped to a different row in each of those several tables, and a single object type attribute may be mapped to several columns in several tables.
Business applications are usually designed to handle only the most common scenarios. The default object types and the default object type attributes, along with their corresponding tables and columns in the data repository, are fixed at the time the application is developed. When an application is deployed, the actual business data is mapped to the default application object types and is stored as rows in the repository tables in the form of object instances.
An example of application data stored in a repository is shown in FIG. 1. At development time, an object type named “City” and an object type named “Product” are included in an application (not shown). A table 110 named “City” and a table 120 named “Product” are created in a repository to store the data for object types “City” and “Product” respectively. Table 110 includes a column 112 with a column name “ID”, a column 114 with a column name “NAME”, and a column 116 with a column name “REGION”. Table 120 includes a column 122 with a column name “ID”, a column 124 with a column name “NAME”, and a column 126 with a column name “DESCRIPTION”.
When the application is deployed, user data is mapped to the “City” and “Product” object types, and is stored as rows of data in tables 110 and 120 respectively. Row 118 is a typical representative of the rows stored in table 110, and, as shown, stores a value “1001” in column “ID”, a value “San Francisco” in column “NAME”, and a value “West Coast” in column “REGION”. Row 128 is a typical representative of the rows stored in table 120, and, as shown, stores a value “1011” in column “ID”, a value “Wheel” in column “NAME”, and a value “For Cars” in column “DESCRIPTION”.
However, since most applications are generic and are designed to handle only the most common scenarios, the user data almost never completely maps to the default object types. The user may have data that does not fit into the default object types but is nevertheless vital for the operation of the business. In order to be able to store and use such data, the user needs to extend the application by adding new object types or by adding custom attributes to existing object types.
An example of such a scenario is illustrated in FIG. 2. With respect to object type “City”, the user needs to add the custom attributes “POPULATION” and “STATE”. Similarly, with respect to object type “Product”, the user needs to add the custom attribute “CATEGORY”. In addition, the user needs to add a new object type “County” with attributes “ID”, “COUNTY_NAME”, “COUNTY_STATE”, and “COUNTY_AREA”.
In order to be able to store the data for the new custom attributes of the object type “City”, table 110 must be extended to include a column 210 with a column name “POPULATION”, and a column 212 with a column name “STATE”. Values for these custom attributes may be stored in table 110. For example, row 118 stores a value “700,000” in column “POPULATION” and a value “California” in column “STATE”. Similarly, in order to be able to store the data for the new custom attribute of the object type “Product”, table 120 must be extended to include a column 216 with a column name “CATEGORY”. Values for the “CATEGORY” custom attribute may then be stored in table 120. For example, row 128 stores a value “Automotive” in column “CATEGORY”.
In order to be able to store the data for the new object type “County”, a new table 220 with a name “County” needs to be created. Table 220 includes a column 222 with a column name “ID”, a column 224 with a column name “COUNTY_NAME”, a column 226 with a column name “COUNTY_STATE”, and a column 228 with a column name “COUNTY_AREA”. Row 230 is a typical representative of the rows stored in table 220, and, as shown, stores a value “1021” in column “ID”, a value “Cook” in column “COUNTY_NAME”, a value “Illinois” in column “COUNTY_STATE”, and a value “850” in column “COUNTY_AREA”.
Scenarios like the one described above arise very often when generic applications with default object types are used to store user-specific data. One problem with extending the repository tables in this manner is that the application may not be able to recognize the custom tables and the custom attributes, and may become unstable or even may completely stop functioning.
Furthermore, upon an upgrade of the application, data stored in the custom tables and in the custom columns of existing tables is typically lost because the upgraded application is not aware of any previously-made user customizations. Thus, the upgrade operation itself does not account for all custom changes to the repository tables that a user can possibly make. A typical application upgrade operation first creates new tables supporting the object types included in the upgrade, copies the data from the old tables to the new tables, and deletes the old tables. Since the upgrade operation is not aware of any custom columns added by the user, the operation does not structure the new tables to support the custom attributes and does not copy the data for these custom attributes in the new tables. Moreover, the typical upgrade operation does not account at all for any custom tables that were added by the user.
One solution to the problem of losing the user-customizations during an upgrade operation is design the application with knowledge of additional, initially unused columns within the repository tables. When customization is needed, the user can use one or more of the “extra” columns to store data for the new custom attributes that need to be added to the existing object types. Because the application knows that the extra columns exist, the extra columns, and any data stored therein, may be taken into account during the upgrade operation. Specifically, the upgraded version of the application may define tables with extra columns as well, and data from the extra columns of the old tables may be copied into the extra columns of the new table during the upgrade operation.
The use of extra application-established columns, however, has several major disadvantages. First, leaving additional unused columns in the repository tables puts a limit on the number of custom attributes that a user can add to the object types of the application. Second, leaving a large number of unused columns in repository tables creates a lot of unnecessary overhead when data in the table is accessed, and, in the case of tables with large number of rows, may lead to a huge waste of storage space. Third, the extra application-established columns solution only allows for new attributes of existing object types, and does not at all address the issue of extending the application to support entirely new object types.
Based on the foregoing, it is desirable to provide a technique by which the user of an application can extend the existing object types with a virtually unlimited number of additional attributes without adding any new columns to existing tables, and can create any number of additional object types in the repository without adding any new tables.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.